Module Quests

Preface
Quest Flags Bare-bones for New Quests Other notes
Tuple Documentation of module_quests.py
Each quest record contains the following fields:
1) Quest id: used for referencing quests in other files. The prefix qst_ is automatically added before each quest-id.
2) Quest Name: Name displayed in the quest screen.
3) Quest flags. See header_quests.py for a list of available flags.
4) Quest Description: Description displayed in the quest screen.
Note that you may call the opcode setup_quest_text for setting up the name and description

module_quests.py is a small, simple file. It contains quests, including all the text related to those quests. Putting new quests here allows them to be activated via the module system, so that operations can read the quest's current status and use that status as a condition operation. It also defines a quest object, for which the aforementioned slots can be used. Example of a quest:

								
									 ("deliver_message", "Deliver Message to {s13}", qf_random_quest,

									  "{!}{s9} asked you to take a message to {s13}. {s13} was at {s4} when you were given this quest."

									  ),

This quest is one of many generic delivery request a king may give you.[1] Tuple breakdown:

								
									1) Quest id = "deliver_message"

									2) Quest Name = "Deliver Message"

									3) Quest flags = qf_random_quest

									4) Quest Description = "{s9} asked you to take a message to {s13}. {s13} was at {s4} when you were given this quest."

This quest uses string registers ({s9}, {s13}, and {s4}) to indicate who gave the quest({s9}), the recipient ({s13}), and where the target was last seen ({s4}). Looking at similar quests, it would seem that {s9} is always used as the requester's name, {s13} is the intended target troop/party and {s4} is used as their last location.

In the progress of creating a new quest, you will be using some of the in section Module Contants mentioned slots for your quest. This way, the value can be set in one place, and if it needs to be changed you only need to change it in one place. The other benefit is that if the player has more than one quest active, you don't have to worry that you might be over-writing variables we defined. Each quest (like all tuple objects) has its own slots.

You will quickly notice that it takes only a few changes to make a new quest, but incorporating it into the game requires a lot more work. You need a place for the player to get the quest, the "actors" that will play a part in the quest and some dialog to make it interesting.

Quest Flags

If you wish to make a quest without any flags, simply put a 0 in the flags field. Otherwise you have the following two available:

qf_show_progression shows what percentage of this quest is completed.
qf_random_quest determines that this quest is a random one.

Bare-bones for New Quests [2]

Here is the bare-bones way to create new quests with MABL. First, you need a consequence block (at the end of a dialogue line, for example) that begins your quest, such as this one:

								
									[[assign,"$do_stuff_quest_active",1],

									[setup_quest_text,"qst_do_stuff"],

									[start_quest,"qst_do_stuff"]]],
  • [[assign,"$do_stuff_quest_active",1], is just a string, not related to the actual quest but handy for coding quest-related condition and consequence blocks later.
  • [setup_quest_text,"qst_do_stuff"], activates the quest text for qst_do_stuff. From experience, this is not strictly necessary but it pays to play things safe.
  • [start_quest,"qst_do_stuff"]], is the consequence that will actually begin your quest.

You can use this kind of consequence block in module_dialogs.py, module_game_menus.py and module_triggers.py (and in others probably as well).

Next, you have to input your quest text at the bottom of module_quests.py:

								
									("do_stuff", "Do some really amazing stuff", qf_show_progression,

									"Some guy asked you to do some really amazing stuff, and he'll give you some gold."

									),
  • ("do_stuff", "Do some really amazing stuff", qf_show_progression, is where most of the action happens. The first string sets up the name of your quest, the second string sets up the short text as you will see it in the top left-hand bar of the quest window, and then come the quest flags, which determine whether you want this to be a random quest (qf_random_quest) OR if you want to show what percentage of this quest is completed (qf_show_progression). It should be possible to put a 0 there if you don't want any quest flags.
  • "Some guy asked you to do some really amazing stuff, and he'll give you some gold." is the long quest text that will show up in the large top-right window of the quest screen.
  • And ), closes your block as you might have guessed already.

Having done this, input whatever content (dialogue, fights and so on) you want this quest to have.

With everything else done the time has come to close your quest:

								
									[[add_xp_as_reward,100],

									[complete_quest,"do_stuff"],

									[set_quest_progression,"qst_do_some_more_stuff",40],

									[assign,"$quest_succeeded_do stuff",1]]],
  • [[add_xp_as_reward,100], is a way to add XP as a reward for your quest. There are other ways to reward the player as well, such as add_gold_to_troop, add_item_to_troop, and so on.
  • [complete_quest,"do_stuff"], completes your quest. You can also use succeed_quest or fail_quest, but they are not really necessary when you can use a simple string to do the same job.
  • If you have set the qf_show_progression flag on your quest, use the operation [set_quest_progression,"qst_do_some_more_stuff",40], to adjust the percentage shown. 40, in this example, will show the quest "do_some_more_stuff" as 40 % complete.
  • [assign,"$quest_succeeded_do stuff",1]]], is a string you can use for future conditions blocks which depend on whether the player has succeeded, failed or otherwise finished the quest. You can make the string anything you like and use any number of strings for this purpose.

This is all you need for a basic quest. More complex ones will require more complicated finagling, especially quests involving heroes.

Other Notes

quests and slots (also later messages at that page), Khamukkamu and kalarhan, Modding Q&A

quests, kalarhan, Modding Q&A

  • Remarks and Sources:
  • [1] This specific quest is defined as the first governer quest in module_constants.py, as you can read in the comment above it. Again, if comments are given, read them. In most cases they contain useful informations for you.
  • [2] Taken from Winter, Modding Q&A. However, it was written for an older version of the Module System and might therefore be outdated, thus verification needed.